REPORT  DOCUMENTATION  PAGE 


Form  Approved 
OMB  No .  0704-0188 


Public  reporting  burden  for  this  collection  of  Information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  Information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information,  including 
suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington,  VA 
22202-4302,  and  to  the  Office  of  Management  and  Budget,  Paperwork  Reduction  Project  (0704-0188),  Washington,  DC  20503. 


3.  REPORT  TYPE  AND  DATES  COVERED 

Professional  Paper 


5.  FUNDING  NUMBERS 

Not  available 


1.  AGENCY  USE  ONLY  (leave  blank) 

2.  REPORT  DATE 

October  1998 

4.  TITLE  AND  SUBTITLE 

A  Central  Architecture  Repository  for  C4ISR  Systems  Interoperability 

6.  AUTHOR(S) 

G.  Nguyen,  and  J.  Walsh,  III 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Space  and  Naval  Warfare  Systems  Center 

San  Diego,  CA  92152-5001 

8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 


9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 


11.  SUPPLEMENTARY  NOTES 


19990630  090 


12a.  DISTRIBUTION/AVAILABILITY  STATEMENTS 


12b.  DISTRIBUTION  CODE 


Approved  for  public  release;  distribution  is  unlimited. 


13.  ABSTRACT  (Maximum  200  words) 

For  the  past  few  years,  the  Space  and  Naval  Warfare  Systems  Command  (SPAWAR)  has  been  developing  a  Naval 
Architecture  Database  (NAD)  designed  to  integrate  the  Navy's  C4ISR  operational,  systems,  and  technical  architectures  in 
order  to  support  users  represented  by  the  program  managers,  systems  engineers,  and  their  equivalents  at  other 
CINCs/Services/ Agencies.  Several  systems  related  applications,  models,  and  tools  use  this  architectural  information  to 
support  C4ISR  decision  making.  Each  of  these  applications  addresses  a  different  and  specialized  aspect  of  the  systems 
engineering  process.  Addressed  from  an  archi  tectural  level,  it  appeal's  that  most  if  not  all  of  these  applications  may  be 
supported  by  the  same  set  of  C4ISR  systems  related  data.  Process  and  business  efficiencies  can  be  realized  if  a  centralized 
information  repository  is  populated  in  order  to  distribute  accurate  and  timely  information  to  support  all  systems  engineering 
applications.  Metadata  and  production  datafills  could  and  should  be  shared.  Once  the  central  repository  is  established,  various 
different  systems  applications  may  be  added  to  a  modular  structure,  easing  change  management.  A  fully  populated  central 
architecture  repository  could  also  be  used  to  provide  decision  support  systems  with  the  capability  to  query  across  systems 
application  boundaries  to  provide  management  with  forecasting,  trend  analysis,  and  knowledge-based  capabilities  combining 
topics  such  as  fleet  deployment,  systems  capabilities,  budget  modeling,  and  systems  architecture.  This  paper  describes  the 
C4ISR  systems  engineering  requirements  that  we  have  gathered  and  the  methodologies  that  we  have  applied  in  building  a 
central  architecture  repository  to  provide  C4ISR  systems  interoperability  information.  We  will  describe  several  initiatives 
within  the  Command  which  require  an  integrated  enterprise  solution  which  we  will  describe  in  die  paper.  As  our  project  is  not 
completed,  the  paper  also  includes  not  only  expected  benefits,  but  also  issues  that  need  to  be  resolved  before  a  production 
systems  interoperability  repository  is  fully  functioning. 

Published  in  Proceedings  of  AFCEA,  MILCOM’98,  October  18*21,  1998. 


14.  SUBJECT  TERMS 


Mission  Area:  Command  and  Control 

central  architecture  repository  Naval  Architecture  Database  (NAD) 
decision  support  systems  production  systems  interoperability  repository 


15.  NUMBER  OF  PAGES 


16.  PRICE  CODE 


17.  SECURITY  CLASSIFICATION 
OF  REPORT 


18.  SECURITY  CLASSIFICATION 
OF  THIS  PAGE 


19.  SECURITY  CLASSIFICATION 
OF  ABSTRACT 


20.  LIMITATION  OF  ABSTRACT 


Same  as  Report 


NSN  7540-01  -280-5500 


Starxiard  form  298  (FRONT) 


NSN  7540-0 1  -280-5500 


Standard  form  298  (BACK) 


UNCLASSIFIED 


A  CENTRAL  ARCHITECTURE  REPOSITORY 
FOR  C4ISR  SYSTEMS  INTEROPERABILITY 


John  Walsh  III 

Space  and  Naval  Warfare  Systems  Command,  Office  of  the  Chief  Engineer 

San  Diego,  California 

Giao  Nguyen 

SPAWAR  Systems  Center 
San  Diego,  California 


ABSTRACT 

For  the  past  few  years,  the  Space  and  Naval  Warfare 
Systems  Command  (SPAWAR)  has  been  developing  a 
Naval  Architecture  Database  (NAD)  designed  to  inte¬ 
grate  the  Navy ’s  C41SR  operational,  systems,  and  tech¬ 
nical  architectures  in  order  to  support  users  represented 
by  the  program  managers,  systems  engineers,  and  their 
equivalents  at  other  CINCs/Services/Agencies.  Several 
systems  related  applications,  models,  and  tools  use  this 
architectural  information  to  support  C4ISR  decision 
making.  Each  of  these  applications  addresses  a  different 
and  specialized  aspect  of  the  systems  engineering  proc¬ 
ess.  Addressed  from  an  architectural  level,  it  appears 
that  most  if  not  all  of  these  applications  may  be  sup¬ 
ported  by  the  same  set  of  C41SR  systems  related  data. 
Process  and  business  efficiencies  can  be  realized  if  a 
centralized  information  repository  is  popidated  in  order 
to  distribute  accurate  and  timely  information  to  support 
all  systems  engineering  applications.  Metadata  and  pro¬ 
duction  datafills  could  and  should  be  shared.  Once  the 
central  repository  is  established,  various  different  sys¬ 
tems  applications  may  be  added  to  a  modular  structure, 
easing  change  management.  A  filly  populated  central 
architecture  repository  could  also  be  used  to  provide 
decision  support  systems  with  the  capability  to  query 
across  systems  application  boundaries  to  provide  man¬ 
agement  with  forecasting,  trend  analysis,  and  knowl¬ 
edge-based  capabilities  combining  topics  such  as  fleet 
deployment,  systems  capabilities,  budget  modeling,  and 
systems  architecture.  This  paper  describes  the  C4ISR 
systems  engineering  requirements  that  we  have  gathered 
and  the  methodologies  that  we  have  applied  in  building 
a  central  architecture  repository  to  provide  C4ISR  sys¬ 
tems  interoperability  information.  We  will  describe  sev¬ 
eral  initiatives  within  the  Command  which  require  an 
integrated  enterprise  solution  which  we  will  describe  in 
the  paper.  /4s  our  project  is  not  completed,  the  paper 
also  includes  not  only  expected  benefits,  but  also  issues 


that  need  to  be  resolved  before  a  production  systems 
interoperability  repository  is  fully  functioning. 

BACKGROUND/INTRODUCTION 
The  Office  of  the  Chief  Engineer  at  the  Space  and  Naval 
Warfare  Systems  Command  (SPAWAR-05)  provides 
unifying  management  and  technical  direction  for  the  de¬ 
velopment,  deliver)'  and  support  of  Naval  C4ISR  sys¬ 
tems.  In  order  to  streamline  the  Information  Technology 
acquisition  process  of  the  command,  an  information  in¬ 
frastructure  must  be  matured  to  meet  the  demand  of  an 
18-month  procurement  cycle  critical  to  remaining  inside 
the  commercial  technology  cycle.  C4ISR  acquisitions 
must  start  with  an  architectural  view  of  the  current  and 
projected  systems  implementations  to  determine  where 
and  how  a  new  acquisition  will  fit  into  the  existing  infra¬ 
structure.  Figure  1  of  the  organizational  structure  of 
SPAWARSYSCOM  illustrates  the  span  of  responsibility 
and  consequently,  requirements  necessary  to  support  an 
interoperable  C4ISR  solution,  making  portions  of  the 
organization  responsible  for  the  system  from  cradle  to 
grave. 
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Figure  1:  SPAWAR  organization  1 
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REQUIREMENTS 

Architecture  is  defined  in  the  C4ISR  Architecture 
Framework  2.0  2  as  the  structure  of  components,  their 
relationships,  and  the  principles  and  guidelines  govern¬ 
ing  their  design  and  evolution  over  time. 

Interoperability,  as  applied  to  the  C4ISR  systems  engi¬ 
neering,  is  defined  as  “the  ability  of  systems,  units,  or 
forces  to  provide  services  to  or  accept  services  from 
other  systems,  units,  or  forces  and  to  use  the  services  so 
exchanged  to  operate  effectively  together.  The  condi¬ 
tions  achieved  among  communications-electronics  sys¬ 
tems  or  items  of  communications-electronics  equipment 
when  information  or  services  can  be  exchanged  directly 
and  satisfactorily  between  them  and/or  their  users.” 3 
In  C4ISR  systems  acquisition,  several  areas  require 
authoritative,  centralized  data: 

1.  Interoperability  Analysis 

2.  Budget  Modeling 

3.  Systems  Capabilities  mapping  and  analysis 

4.  C4ISR  Architecture  drawings  (Ring  Charts) 

5.  Configuration  management  tracking 

6.  Logistics  support  information 

7.  C4ISR  Measures  of  Effectiveness  and  Per¬ 
formance  to  support  Test  and  Evaluation 

8.  Critical  system  attributes  to  feed  M&S 

9.  Tactical  tasks  performed  by  C4ISR  systems 

10.  Systems  performance  data 

Given  the  above  business  requirements  to  field  interop¬ 
erable  systems,  we  have  taken  an  innovative  approach  in 
extracting,  transforming,  and  loading  critical  information 
into  a  central  repository  which  allows  command-wide 
synchronization  for  the  current  and  planned  state  of  the 
naval  C4ISR.  This  integrated  information  warehouse  and 
repository  will  allow  a  global  view  of  C4ISR  and  allow 
managers  to  make  informed  decisions  with  the  depth  and 
breadth  necessary  to  maximize  the  use  of  critically  short 
funding  in  the  Department  of  Navy  today. 

THE  METHODOLOGY/ARCHITECTURE 
This  project  has  delineated  critical  areas  in  the  C4ISR 
acquisition  infrastructure  that  require  centralized,  nor¬ 
malized,  and  integrated  information  to  insure  that  our 
acquisitions  truly  follow  the  SPAWAR  mission  to  “de¬ 
liver  supportable,  affordable,  integrated,  and  interoper¬ 
able  world  class  information  solutions.” 

SYSTEMS  ARCHITECTURE 
In  order  to  field  an  interoperable  system,  a  documented 
C4ISR  current  architecture  must  exist  to  understand  a 
system’s  inter-relationships  with  other  systems. 
Additionally,  a  target  architecture  must  be  developed  to 
support  the  Operational  Architecture  of  the  future.  A 
Naval  Architecture  Database4,  developed  at  SPAWAR 
051,  containing  all  the  Naval  C4ISR  Systems,  Opera¬ 
tional,  and  Technical  Architecture  views  will  support 


C4ISR  architecture  analysis,  both  As-Is  and  Target  ar¬ 
chitectures  with  fully  attributed  Information  Exchange 
Requirements  tied  to  tactical  tasks  and  the  available 
standards  used  to  manipulate  and  transmit  the  informa¬ 
tion. 

The  Joint  C4ISR  Architecture/Planning  and  Analysis 
System  (JCAPS)  is  a  suite  of  tools.  This  toolbox  allows 
the  user  to  access  existing  and  future  C4ISR  architec¬ 
tures  and  visualize  them  in  the  Framework  2.0  format  as 
directed  by  OSD.  These  architectures  will  be  used  to 
support  C4ISR  Master  Plans  required  in  the  DoD  5000.2 
process.  These  operational,  system,  and  technical  views 
of  the  architecture  will  allow  the  user  to  manipulate  the 
architecture  and  understand  the  ripple  effects  of  pro¬ 
posed  or  actual  changes  to  the  infrastructure.  The  Core 
Architecture  Data  Model  2.0  5  has  been  mapped  to  the 
Naval  Architecture  Data  Model  2.1  4  with  98%  congru¬ 
ence.  This  compatibility  will  allow  users  of  the  NAD  to 
exchange  architecture  data  with  other 
CINCs/Services/ Agencies . 

SYSTEMS  ENGINEERING 
In  order  to  design  a  system  to  inter-operate  with  several 
legacy  systems,  a  detailed  understanding  of  the  installed 
systems  must  exist.  Representations  of  this  complex  in¬ 
frastructure  must  be  simple  enough  for  human  under¬ 
standing  of  the  first  and  second  order  effects  of  a  deci¬ 
sion  made  within  the  systems  engineering  process.  The 
use  of  C4ISR  As-Is  Architecture  drawings  called  “Ring 
Charts”  are  used  to  visualize  the  relationships  between 
systems  drilling  through  a  hierarchy  starting  at  the  battle 
group  level  down  to  a  particular  component  of  a  plat¬ 
form.  As  these  drawings  are  developed,  COTS  drawing 
packages  will  generate  the  data  behind  these  drawings  to 
establish  the  relationships,  links,  and  attributes  associ¬ 
ated  with  those  systems.  The  example  shown  in  Figure  2 
is  representative  of  a  system-level  Ring  Chart  for  an  air¬ 
craft  carrier. 
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YEAR  2000  COMPLIANCE  (Y2K) 

All  current  and  projected  systems  must  be  Y2K  compli¬ 
ant.  In  order  to  facilitate  compliance,  systems  must  be 
tracked  from  a  centralized  location  and  an  up-to-date 
status  of  the  testing  stored.  Additionally,  Memorandums 
of  Agreement  (MOA)  are  generated  between  program 
offices  to  insure  that  an  agreed  interface  protocol  exists 
to  insure  that  Y2K  interfaces  are  compliant.  Integration 
of  the  Navy-wide  Y2K  compliance  database  with  the 
C4ISR  architecture  is  critical  in  understanding  the  Navy 
infrastructure  vulnerabilities.  The  ability  to  trace  Y2K 
compliance  throughout  C4ISR  architecture  should  be 
built-in  as  systems  are  being  added  to  the  Naval  Archi¬ 
tecture  Database. 


VISION  DOCUMENTS 

There  are  several  visions  and  proposed  architectures  that 
need  to  be  mapped  against  the  current  C4ISR  architec¬ 
ture  in  order  to  develop  well  planned  migration  plans. 

•  Information  Technology  for  the  2 lsl  Century 

•  Joint  Vision  2010 

•  Copernicus  Forward 

•  Navy  Virtual  Internet 

•  Integrated  Information  Base  Architecture 

In  order  to  be  truly  interoperable  with  the  tactical  envi¬ 
ronment,  we  need  to  insure  that  the  infrastructure  that  is 
established  in  the  non-tactical  environment  will  be  inter¬ 
operable  with  the  operational  environment.  For  instance, 
the  naming  convention  (noun  name,  hull  number  or 
some  defined  combination)  for  fleet  units  needs  to  be 
consistent  across  all  systems. 


SYSTEMS  MANAGEMENT  INTEGRATED 
DATA  BASE  (SMIDB) 

For  the  installation  of  systems  to  support  the  Navy  Vir¬ 
tual  Internet  (NVI),  a  proposed  architecture,  and  Infor¬ 
mation  Technology  for  the  21st  Century  (IT21), 
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Figure  3:  SMIDB  integration  to  information  warehouse 


a  technology  insertion  program  must  tie  directly  to  fleet 
capabilities,  mission  requirements,  the  UJTLs,  and  battle 
groups  entities. 

A  management  tool  allowing  a  user  to  visualize  the  in¬ 
teraction  among  schedule,  money,  platforms,  systems, 
organizations,  and  capabilities  is  critical  to  the  planning 
process.  In  order  to  fully  integrate  these  information 
sources,  data  extraction,  transformation,  and  loading 
from  several  legacy  systems  must  occur  in  order  to 
populate  the  database.  Migration  to  a  centralized  re¬ 
pository  as  shown  in  Figure  3  is  critical  to  making  the 
system  a  viable,  long-term  decision  support. 

INTEROPERABILITY  EVALUATION 
The  Level  of  Information  Systems  Interoperability 
(LISI),  sponsored  by  OSD/ASD(C3I)  and  developed  by 
Mitre,  is  a  tool  that  allows  the  user  to  quantify  a  level  of 
interoperability  for  a  system  across  procedures,  applica¬ 
tions,  infrastructure,  and  data  domains.  A  measure  of 
interoperability  across  all  systems  is  required  to  under¬ 
stand  where  capability  holes  exist  in  the  procedures,  ap¬ 
plications,  infrastructure,  and  data  to  support  an  interop¬ 
erable  environment.  SPAWAR  is  currently  evaluating 
the  technical  reference  model  of  LISI  against  several  op¬ 
erational  C4ISR  systems.  A  representation  of  the  current 
levels  of  interoperability  is  shown  in  Figure  4.  This  sys¬ 
tem  is  planned  to  be  part  of  the  SPAWAR  acquisition 
tool  kit  that  is  fed  with  data  from  the  NAD.  Results  of 
the  evaluation  will  also  be  archived  in  the  NAD 
throughout  the  system  lifecycle. 
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Figure  4:  LISI  C4ISR  Assessment  model  6 

MODELING  AND  SIMULATION  SUPPORT 
The  Joint  Maritime  Systems  Analysis  Center  (JMSAC) 
at  SPAWAR  PD  13  and  the  Joint  Chiefs  of  Staff  (JCS) 
NetWars  initiative  are  attempts  to  evaluate  the  perform¬ 
ance  of  a  C4ISR  infrastructure  for  a  specific  mission  and 
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phase  of  war.  The  capability  to  identify  infrastructure 
shortfalls  in  the  architecture  of  a  particular  battle  group 
before  a  mission  is  critical  to  mission  planning  accuracy. 
Reuse  of  actual,  measured  data  from  exercises  around 
the  world  help  model  the  anticipated  message  traffic  as¬ 
sociated  with  a  particular  mission.  This  planning  can 
identify  bottlenecks  in  the  C4ISR  infrastructure  and  pro¬ 
vide  insight  into  the  appropriate  technical  or  operational 
work  required  to  repair  the  anticipated  problems  prior  to 
experiencing  them  in  the  operational  environment. 
JMSAC  is  a  COTS  based  tool  that  provides  simple  and 
quick  evaluation  of  existing  and  to-be  C4ISR  architec¬ 
tures. 


BUDGET  MODELING 

To  ensure  that  the  budget  provided  by  CNO  N6E  at  the 
Program  Element  (PE)  level  feed  the  Work  Breakdown 
Structure  (WBS)  at  SPAWAR,  we  must  trace  the  money 
from  the  Congressional  Budget  to  actual  expenditure  of 
assets.  Funds  must  be  tied  to  capabilities  by  battle  group. 
Web-based  integration  of  the  Data  CUBE  database  with 
the  NAD  and  SMIDB  will  feature  smart  allocation  of 
resources  to  meet  current  tactical  task  requirements,  and 
further  ties  budget  to  existing  infrastructure.  It  is  desir¬ 
able  that  a  Baseline  Assessment  Memorandum  (BAM) 
can  be  performed  on  these  integrated  databases  where 
optimal  slice  and  dice  of  financial  resources  may  be  pro¬ 
posed. 

FLEET  EXERCISE 

As-Is  C4ISR  architecture  performance  data  will  be  cap¬ 
tured  on  operational  systems  through  the  Joint  Network 
Management  System  and  be  used  to  validate  the  existing 
database  content  design  assumptions,  as  well  as  feed 
scenario  based  modeling  and  simulation. 

TYING  IT  ALL  TOGETHER 

The  automation  of  Information  Systems  management 
and  sharing  of  packaged  application  data  has  brought 
substantial  and  rewarding  efficiencies  to  commercial 
business.  These  rewards  are  realized  when  more  timely, 
accurate  and  comprehensive  decisions  are  possible. 
Without  a  centralized,  normalized,  and  distributed  in¬ 
formation  architecture,  critical  decisions  cannot  be  made 
on  all  the  associated  facts.  In  order  to  facilitate  a  com¬ 
mon  information  base  for  the  command  acquisition  in¬ 
frastructure,  we  have  developed  a  high-level  information 
architecture  to  tie  those  disparate  data  sources  together. 
Data  warehousing  and  virtual  data  base  technologies 
combined  with  web  distribution  allow  smart  push  and 
pull  of  the  appropriate  information  to  the  user.  While  we 
will  be  gathering  all  the  critical  data  elements  into  the 
data  warehouse  repository  (Figure  5)  with  a  single  meta¬ 
data  management  area,  we  will  be  able  to  deliver  appro¬ 
priately  sized  and  subject  specific  aggregations  of 


authoritative  data  to  information  customers  to  support 
the  various  business  requirements  (Figure  6)  throughout 
the  Command.  The  final  SPAWAR  C4ISR  Information 
Warehouse  and  Repository  (SCIWAR)  Operating  Capa¬ 
bility  architecture  is  shown  in  Figure  7. 


BENEFITS 

Each  application  runs  on  a  data  mart  produced  by  the 
data  warehouse  will  have  the  latest  aggregation  of  in¬ 
formation  to  support  their  business  process,  to  include 
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Figure  5:  Migration  of  information  into  a  repository 


Figure  6:  True  ETL  using  Data  Warehouse  technology 
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Figure  7:  Initial  Operating  Capability  Architecture 
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the  historical  data  which  allows  the  added  feature  of 
trend  and  time  variance  analysis.  The  open  system  ar¬ 
chitecture  facilitated  by  standardized  information  syntax, 
semantics,  and  web-based  distribution  technologies  is  a 
large  benefit  facilitating  more  interoperable.  Command 
wide  tool  sets.  The  fact  that  new  detailed  analysis  can 
occur  with  centralized  information  will  provide  results 
with  more  breadth  and  depth  allowing  more  discrete 
analytical  capability.  The  addition  of  knowledge  base 
and  data  mining  technologies  will  allow  new  trends  and 
capabilities  to  be  discovered  while  also  adding  cognitive 
reasoning  capability  against  an  authoritative  source  of 
information  for  the  command.  Once  the  data  warehouse 
infrastructure  is  fully  architected  and  established,  new 
data  sources  and  marts  can  be  rapidly  inserted  into  the 
architecture  allowing  quick  response  and  access  to  criti¬ 
cal  information.  Additionally,  rapid  versioning  of  the 
data  marts  keeps  the  business  applications  current  to 
meet  the  changing  business  requirements. 

ISSUES 

Several  implementation  and  supportability  issues  exist  in 
our  project.  The  technical  feasibility  is  being  verified  as 
we  are  bringing  disparate  data  together.  This  will  be 
demonstrated  by  a  Proof  of  Concept  near  the  end  of  this 
calendar  year.  Information  security  is  a  high  priority. 
An  aggregation  of  unclassified  data  can  result  in  a  query 
which  becomes  classified.  Multi-level  security  and  row 
level  data  access  may  be  required  to  truly  automate  the 
integrated  data  environment  use  and  information  distri¬ 
bution.  It  is  critical  that  data  ownership  be  specifically 
established  so  that  timely  and  valid  system  engineering 
data  are  available  to  represent  diversified,  yet  integrated 
aspects  of  C4ISR  systems.  At  the  same  time,  continued 
management  support  and  user  involvement  are  required 
before  a  Naval  Central  Architecture  Repository  for 
C4ISR  Systems  Interoperability  can  become  a  produc¬ 
tion  reality. 

CONCLUSION 

A  central  information  repository  is  required  to  achieve 
true  interoperability  into  the  C4ISR  architecture. 

The  current  state  of  technology  is  available  to  facilitate 
automated  extraction,  transformation,  and  loading  of  in¬ 
formation  and  delivering  authoritative,  aggregations  of 
data  to  a  specific  user.  Certainly,  data  warehouse  tech¬ 
nology  is  one  of  the  major  technical  solutions  to  cen¬ 
trally  managing  the  Command’s  metadata  requirements 
and  increasing  the  interoperability  of  information  itself 
across  the  command. 
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